In the absence of a privacy mechanism, sensitive data (e.g., passwords, account numbers, proprietary information, etc.) transmitted over a public network may be susceptible to interception by unauthorized parties. One privacy mechanism commonly used to protect network data is a Virtual Private Network (VPN). A VPN typically comprises multiple nodes of one or more private networks, which communicate among themselves across a provider network(s) as if the nodes were connected by private lines (i.e., dedicated point-to-point connections). Multiple VPNs can share a common physical infrastructure without compromising the security of each individual VPN.
Most network-based VPNs rely on tunneling to create the “virtual” connections that extend across the public portion of a network backbone. Tunneling is the process of encapsulating a header and/or payload of a packet within another packet prior to transmission of an original packet over the public network. Generally, the transmission of a VPN-based packet only uses the protocol of the public network, for example, the information such as the Internet Protocol (IP) addresses of the ends of the tunnels where the packet enters and exits the public network (referred to as Provider Edge (PE) devices). Sensitive information encapsulated within the VPN-based packet is in essence, transparent to the PE devices and intermediate nodes of the public network. As a result, the sensitive data carried in the encapsulated packet is incomprehensible to anything other than those authorized devices on the private network side connected to an appropriate PE device. Exemplary tunneling protocols include, but are not limited to IP/IP tunneling, Layer-2 Forwarding (L2F) tunneling, Point-to-Point Tunneling Protocol (PPTP), Generic Router Encapsulation (GRE) tunneling, IP Security (IPSec) tunneling, and Multi-Protocol Label Switching (MPLS) tunneling. The configuration of a VPN tunnel is typically specific to the particular type of VPN used.
A typical IP-based VPN generally includes at least two provider edge devices (e.g., a VPN-enabled router) interconnected via a series of provider devices (e.g., routers) that form a network backbone, where the network backbone typically includes one or more public networks, such as, for example, the Internet or a wide area network (WAN). Connected to each PE device are one or more customer edge (CE) devices. As understood in the art, CE devices may include any of a variety of networked devices, such as personal computers, laptops, workstations, and the like. In this type of network-based VPN, VPN tunnels are established between PE devices, rather than between CE devices.
Regardless of the VPN mechanism used, a primary step in establishing a network-based VPN is to provide information about each VPN configured on a local PE device to a remaining remote PE devices. A number of mechanisms may be implemented to achieve this distribution of PE information such as, for example, Border Gateway Protocol (BGP), Domain Name Service (DNS), Remote Authentication Dial In User Service (RADIUS), and the like. See Hamid Ould-Brahim et al., “Using BGP as an Auto-Discovery Mechanism for Provider-Provisioned VPNs,” Internet Engineering Task Force (IETF), August 2003, the entirety of which is hereby incorporated herein by reference. After distributing this PE information, one or more PE-PE tunnels typically are established based in part on information received through the VPN auto-discovery mechanism.
Layer 2 services such as, but not limited to, Frame Relay, Asynchronous Transfer Mode (ATM), and Ethernet may be “emulated” over an MPLS/IP network by encapsulating layer-2 packets and then transmitting them over “pseudo-wires”. A pseudo-wire is a mechanism that carries the essential elements of an emulated service from one PE to one or more other PEs over a Packet Switched Network (PSN). See Luca Martini et al., “Pseudowire Setup and Maintenance Using LDP,” IETF, February 2003, the entirety of which is hereby incorporated herein by reference; Stewart Bryant et al., “PWE3 Architecture,” IETF, June 2003, the entirety of which is hereby incorporated herein by reference; Eric Rosen, “Provisioning Models and Endpoint Identifiers in L2VPN Signaling,” IETF, May 2003, the entirety of which is hereby incorporated herein by reference; and Himanshu Shah, “Extensions to Transport of Layer 2 Frames Over MPLS,” IETF, February 2003, the entirety of which is hereby incorporated herein by reference. One or more pseudo-wires can be carried inside a PSN tunnel.
Referring to FIG. 1, there is shown an exemplary VPN 100 providing a layer-2 emulated service between two customer edge (CE) devices 110 (CE1) and 120 (CE2) via an MPLS/IP network 130. The CE device 110 is connected to a PE device (PE1) 114 via an attachment circuit 118. Similarly, the CE device 120 is connected to a PE device (PE2) 124 via an attachment circuit 128. Connected to each CE device 110 and 120 may be an independent access network (not shown) such as a Local Area Network (LAN). The PE devices 114 and 124 are interconnected via a series of routers or MPLS/IP-enabled layer-2 switches (not shown) that form the MPLS/IP network 130. In this type of network-based VPN, a PSN tunnel 140 is established between PE devices 114 and 124 to encapsulate layer-2 packets transmitted between the CE devices 110 and 120. Inside tunnel 140 is a pseudo-wire 150, which carries the essential elements of the emulated service between PE devices 114 and 124. Although only one pseudo-wire is depicted, it is common to have multiple pseudo-wires carried inside the tunnel 140.
In the event that one end of the pseudo-wire 150 experiences a failure such as a node failure, link failure, or the like, the emulated service provided between customer edge devices 110 and 120 becomes non-operational. In order to reestablish the emulated service in spite of a failure, a new or “backup” pseudo-wire must be employed. Conventional techniques to establish a backup pseudo-wire generally require a person (i.e., an operator) to intervene and manually configure at the non-failing end of the original pseudo-wire a backup endpoint or node in place of the failed end. Manual configuration of a backup pseudo-wire is typically time-consuming, thereby resulting in an undesirable period of time (“downtime”) before the emulated service is restored. In addition, conventional techniques place the burden on the backup site to connect to all remote sites. For example, if a particular layer-2 VPN comprises thousands of spoke sites and the hub failed, the backup site would have to manually or dynamically establish a pseudo-wire to the thousands of the other sites. Such a burden could have the adverse effect of overloading the backup site and potentially putting it at risk of failure as well.
In view of the foregoing, it would be desirable to provide an automatic pseudo-wire recovery technique for layer-2 VPN that establishes a backup pseudo-wire in the event of a failure of the original pseudo-wire without requiring manual intervention.